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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by Joint Technical Committee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 
60 countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-121 8 GRAND SACONNEX (Geneva) 

Switzerland 

Tel:H-41 22 717 21 11 

Fax:-H41 22 717 24 81 

Founded in September 1993, the DVB Project is a market-led consortium of public and private sector organizations in 
the television industry. Its aim is to establish the framework for the introduction of MPEG-2 based digital television 
services. Now comprising over 200 organizations from more than 25 countries around the world, DVB fosters market- 
led systems, which meet the real needs, and economic circumstances, of the consumer electronics and the broadcast 
industry. 
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Scope 



The present document is an addendum to TS 102 034 [4] concerning Broadcast Content Guides (BCG). It provides 
specifications for the signalHng and delivery of TV-Anytime information in DVB-IP services. The BCG addresses both 
Content on Demand and Live Content, whether the content is available as a DVB-IP service or as a pure DVB service. 

It has been written to be compatible as much as possible with TS 102 323 [1], which specifies the signalling and 
delivery of TV-Anytime information in DVB transport streams. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version appUes. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

[I] ETSI TS 102 323: "Digital Video Broadcasting (DVB); Carnage and signalhng of TV-Anytime 
information in DVB transport streams". 

[2] ETSI TS 102 822-3-2: "Broadcast and On-line Services: Search, select and rightful use of content 

on personal storage systems ("TV-Anytime"), Part 3: Metadata; Sub-part 2: System aspects in a 
uni -directional environment". 

[3] ETSI TS 102 822-3-1: "Broadcast and On-line Services: Search, select, and rightful use of content 

on personal storage systems ("TV-Anytime"); Part 3: Metadata; Sub-part 1: Phase 1 - Metadata 
schemas". 

[4] ETSI TS 102 034: "Digital Video Broadcasting (DVB) Transport of MPEG-2 Based DVB 

Services over IP Based Networks". 

[5] IETF RFC 1950: "ZLIB Compressed Data Format Specification version 3.3". 

[6] IETF RFC 1951: "DEFLATE Compressed Data Format Specification version 1.3". 

[7] ETSI TS 102 822-6-1: "Broadcast and On-line Services: Search, select, and rightful use of content 

on personal storage systems ("TV-Anytime"); Part 6: Delivery of metadata over a bi-directional 
network; Sub-part 1: Service and transport". 

[8] "Simple Object Access Protocol (SOAP) 1.1" W3C Note 08 May 2000. 

[9] ISO/IEC 13818-1: "Information technology - Generic coding of moving pictures and associated 

audio information: Systems". 

[10] ISO/IEC 23001-1 (MPEG-B): "Information Technology - MPEG Systems Technology - Binary 

MPEG format for XML". 

[II] ETSI EN 300 468: "Digital Video Broadcasting (DVB); Specification for Service Information (SI) 
in DVB systems". 
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[12] IETF RFC 2326: "Real Time Streaming Protocol (RTSP)". 



[13] ISO 8601 (2004): "Data elements and interchange formats - Information 

interchange - Representation of dates and times". 

[14] IETF RFC 2616: "Hypertext Transfer Protocol - HTTP/1. 1". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Content on Demand (CoD): program provided at the request of the end user for direct consumption (real-time 
streaming) or storage 

Content Provider: entity that owns or is licensed to sell content or content assets 

NOTE: The user could be a person or a PVR or some other entity. 

Delivery Network: network connecting the delivery network gateway and service providers 

Delivery Network Gateway (DNG): device that is connected to one or multiple delivery networks and one or multiple 
home network segments 

DVB-IP service: DVB service provided over IP or content on demand over IP 

DVB service: as defined by DVB, "a sequence of programmes under the control of a broadcaster which can be 
broadcast as part of a schedule" 

event: grouping of elementary broadcast data streams with a defined start and end time belonging to a common service 

EXAMPLE: First half of a football match. News Flash, first part of an entertainment show. 

Home Network End Device (HNED): device that is connected to a home network and which typically terminates the 
IP based information flow (sender or receiver side) 

package: collection of DVB services marketed as a single entity 

program: collection of program elements 

NOTE: Program elements may be elementary streams. Program elements may have a common time base for 
synchronized presentation. 

Service Provider (SP): entity providing a service to the end-user. In the context of the present document, SP will mean 
a Service Provider providing DVB-IP services 

SP offering: set of streams or services a Service Provider proposes to the end-user 

Transport Stream: data structure defined in ISO/IEC 13818-1 [9] 

TS Full SI: transport stream with embedded service information as defined by DVB in EN 300 468 [11] with the 
exception of the network information table NIT 

NOTE: This table may be omitted as it has no meaning in the context of IP services. 

TS - Optional SI: A transport stream with MPEG PSI (PAT and PMT tables) as defined in ISO/IEC 13818-1 [9] 

NOTE: All other MPEG-2 and DVB tables are optional. 
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3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

BCG Broadband Content Guide 

BiM Binary format for Multimedia description streams 

CoD Content on Demand 

CRI Content Referencing Information 

CRID Content Reference IDentifier 

DNG Delivery Network Gateway 

DVB Digital Video Broadcasting 

DVBSTP DVB SD&S Transport Protocol 

HNED Home Network End Device 

HTTP Hyper Text Transfer Protocol 

IMI Instant Metadata Identifier 

IP Internet Protocol 

IPI Internet Protocol Infrastructure 

MPEG Moving Pictures Expert Group 

RAR Resolving Authority Record 

RNT RAR Notification Table 

RTSP Real Time Streaming Protocol 

SD&S Service Discovery and Selection 

SOAP Simple Object Access Protocol 

SP Service Provider 

URL Uniform Resource Locator 

XML extensible Markup Language 



Delivery of BCG data 



BCG data MAY be delivered in one of two ways: 

• Container-based: 

via multicast (i.e. pushed); 
via unicast (i.e. pulled). 

• Query: 

via unicast. 

The IPI-1 interface SHALL support the container-based mechanism, both via multicast and unicast. It MAY 
additionally support the query mechanism. 

On all networks there SHALL be at least one BCG provider that supports the container based download mechanism. 
Additionally, this provider MAY support the query mechanism. 

For clarification, the query mechanism is optional for both Service Providers and HNEDs. 

The container based download mechanism uses the Data Delivery Unit, as specified in clause 4.1.1.3, delivered via the 
mechanisms specified in clause 4.2. 

The query mechanism is specified in clause 4.3. 
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4.1 Container-Based Delivery 

4.1.1 Definitions 
4.1.1.1 Container 

A container shall carry either a RNT, one or more CRI structures or Metadata. Each container is distinguished by a 
unique identifier, which is the container_id. Table 1 shows the clauses in the present document where the container 
format, according to each type of data carried, is defined. 

Table 1 : Container Format Definitions 



Type of data carried 


Container Format Definition 


RNT 


Clause 5.1 in the present document 


CRI structures 


TS 102 323 [1], clause 7.3.1.3 


Metadata 


TS 102 323 [1], clause 9.3 



The type of data that the container carries determines the scope and format of the structure values. 

4.1 .1 .2 Compression wrapper 

The compression_wrapper allows a container to be carried in a compressed or uncompressed format. The syntax of the 
compression_wrapper is defined in table 21, clause 7.3.1.5 of TS 102 323 [1]. The compression_wrapper shall always 
be present, whether or not the container is compressed. 

The semantics of the fields of table 21, clause 7.3.1.5 of TS 102 323 [1] are modified as follows: 

• container(): See clause 4.1.1.1 for the definition of the container structure. 

NOTE: This definition differs from TS 102 323 [1], where the compression wrapper may contain CRI structures 
only. 

• compression_structure: This shall contain a container (see clause 4.1.1.1) encoded as a Zlib stream 

(as defined in RFC 1950 [5]). When present, the Zlib stream shall have its compression method nibble set to 
"1000", indicating use of the Deflate compression algorithm as specified in RFC 1951 [6]. 

4.1.1.3 Data Delivery Unit 

A Data Delivery Unit is a container, as defined in clause 4.1.1.1, within a compression wrapper as defined in 
clause 4.1.1.2. 

4.1.2 Transport 

4.1 .2.1 SD&S Information Data Types 

In addition to the Payload ID values defined in TS 102 034 [4] table 1 clause 5.2.2.1, the values defined in table 2 shall 
be used for the BCG Data Delivery Units. 
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Table 2: BCG Payload ID values 



Payload ID value 


Payload type carried 


OxA1 


DVB-TVA-init message (clause 7.3 in the present document) 


0xA2 


TVAMain fragment (clause 7.4 in the present document) 


0xA3 


TV-Anytime metadata data container (clause 9.2.2 of TS 102 323 [1]), value "d" in table 47) 


OxA4 


TV-Anytime metadata index container (clause 9.2.2 of TS 102 323 [1], value "i" in table 47) 


0xA5 


Both TV-Anytime metadata data and index container (clause 9.2.2 of TS 102 323 [1], 
value "b" in table 47) 


0xA6 


RNT (clause 5.1 in the present document) 


0xA7 


CRI structure (clause 5.3 in the present document) 


0xA8-0xAF 


Reserved 



4.1.2.2 



Transport mechanisms 



This clause specifies the protocols that are used to transport the BCG information. Two mechanisms are defined, one 
for multicast and one for unicast. 

The protocol DVB SD&S Transport Protocol (DVBSTP), as specified in clause 5.4.1 of TS 102 034 [4], shall be used 
to transport BCG information over multicast. 

The protocol HTTP [14] shall be used to transport BCG information over unicast. 

The two transport mechanisms shall be interchangeable in all steps and carry the same content encoded in the same 
way. 



4.1.2.2.1 



Protocol for Multicast Delivery of BCGs 



For the push model delivery of BCGs, the protocol DVBSTP, as defined in TS 102 034 [4], clause 5.4.1.2, shall be used 
to transmit Data Delivery Units, as defined in clause 4.1.1.3 of the present document. Additional semantics are defined 
for the following fields: 

• Payload ID: The Payload ID shall be encoded as specified in table 2 of the present document. 

• Segment ID: If the Payload ID value is OxA3, 0xA4 or OxA5, then this field has the semantics of the 
container_id defined in TS 102 822-3-2 [2], clause 4.5.1.3. If the Payload ID value is 0xA7 then this field has 
the semantics of the container_id defined in TS 102 323 [1], clause 7.3.1.1. 

• Segment Version: If the Payload ID value is OxA3, 0xA4 or OxA5, then this field has the semantics of a 
container version identifier defined in TS 102 822-3-2 [2], clause 4.5.1.2. 

• Compression (Compr): Additional compression values are defined in table 3. 

The field value of "001" is used to signal the encoding defined in the present document, which will be either BiM [10] 
for XML data or a specific binary representation for non XML data (RNT, CRI etc.). Use of other values in the 
compression field is not defined. 

Table 3: Additional Compression Values 



Compression value 


Meaning 


Total Segment Size Meaning 


001 


Either BilVI or the specific binary 
representation defined in the 
present document 


Transmitted Size 
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4.1.2.2.2 



Protocol for Unicast Delivery of BCGs 



In the pull model of delivery of BCGs, the HTTP [14] protocol shall be used for all communication between the HNED 
and the BCG server(s). 

When the HNED requests BCG information, it shall use the format defined in TS 102 034 [4], clause 5.4.2. The 
Payload ID values used shall be as defined in table 2 of the present document. The segmentID values shall have the 
same semantics as defined in TS 102 034 [4], clause 5.4.1.2. The BCG server(s) shall return Data Delivery Units, as 
defined in clause 4.1.1.3 of the present document. 

When the HNED requests BCG information, it shall use the following format: 

"GET /dvb/sdns/bcg_request HTTP/1.1" CRLF 
"Host: " host CRLF 

The bcg_request shall comply with the following format: 

bcg_request = bcg?Payload="PayloadId"&Segment="Segment Item" 

where: 

Payloadid = OCTET; any hex number from 0x00 to Oxff 
Segmentid = 4*4 HEXDIG;any hex number from 0x0000 to Oxffff 
Segmentltem = Segmentid 0*1 ( ' & ' VersionNumber ) 

Segmentltem is a Segmentid with an optional field for the version number. 

VersionNumber = OCTET; any hex number from 0x00 to Oxff 

For example, the following request can be constructed to request the index list structure (see TS 102 323 [1], 
clause 9.2.2): 

"GET /dvb/sdns/bcg?Payload=0xA4&Segment=0x0000 HTTP/1.1" CRLF 
"Host: " host CRLF 

The HTTP headers returned with the data shall be: 

Content-encoding : x-bim 

4.2 Query mechanism 

The query mechanism for BCG acquisition is described in this clause. 

When the query mechanism is used, it SHALL be implemented according to TS 102 822-6-1 [7] and the requirements 
described in this clause. TS 102 822-6-1 [7] describes four SOAP methods. The version of SOAP [8] used SHALL 
be 1.1. 

Table 4 below shows the status of these methods within the present document. 

Table 4: Requirements for Service Providers and HNEDs relating to SOAP methods 

as defined in TS 102 822-6-1 





Service Provider 


HNED 


get Data 


M 


M 


describe Get Data 


M 


M 


submit Data 








describe_Submit_Data 


(if submit_Data not supported) 
IVI (if submit_Data supported) 
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5 Content Resolution 

Content resolution is performed as in TS 102 323 [1], with the following additional constraints. 

5.1 RNT (Resolution Provider Notification Table) 

This table shall be carried inside a Data Delivery Unit, as defined in clause 4.1.1.3 of the present document. 

The syntax and semantics of table 1 of clause 5.2.2 of TS 102 323 [1] shall be used, but deleting all the fields preceding 
the common_descriptors_length field, except the last 4 reserved bits. This removes all references to table sections, 
context_id and context_id_type, which are not relevant to the present document 

5.2 BAR over IP descriptor 

The RAR over IP descriptor defined in TS 102 323 [1], clause 5.3.6 shall have the following additional semantics: 

• urMength: The length of the URL. A length of can be used to indicate that the CRI structures shall be 
transmitted via the URL that is currently used. 

• url_char: If present, this field shall contain a URL. The rules governing the encoding of an URL shall be as 
defined in clause 6.2 of TS 102 323 [1]. 

5.3 CRI structures 

The format of CRI structures defined in TS 102 323 [1], clause 7.3.1.3 shall be used. 

This structure shall be carried inside a Data Delivery Unit, as defined in clause 4.1.1.3 of the present document. 

NOTE: The container carrying the cri_index structure, which is the first structure required by the receiver, shall 
have its Segment ID set to 0x0000, as specified by TS 102 323 [1], clause 7.3.1.1. 

6 Profile of TV-Anytime Metadata for BCG 

6.1 Introduction 

TS 102 822-3-2 [2] provides several options for how to structure descriptions of program, group and location 
information. The present clause defines the options that are either mandatory, optional or not used for BCG information. 
The profile as specified in TS 102 323 [1], clause 8 shall apply unless explicitly stated below. 

NOTE: The present document does not provide any profiling for metadata delivered by other means. 

6.2 Summary 

The fragments defined in TS 102 822-3-2 [2], clause 8.2 shall be used. The following clauses provide further details as 
needed. 

6.3 Programlnformation fragment 

The Programlnformation fragment shall be defined as in TS 102 323 [1], clause 8.3. 

6.4 Grouplnformation fragment 

The Grouplnformation fragment shall be defined as in TS 102 323 [1], clause 8.4. 
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6.5 Schedule fragment 

The Schedule fragment shall be defined as in TS 102 323 [1], clause 8.5. 

6.6 Servicelnformation fragment 

Optional elements that are absent in a Servicelnformation element may be taken from SD&S information. 

The Name element may be an empty element, in which case it shall be inferred from the SD&S information of that 
service. 

If an optional field is not specified, its contents shall be inferred from the SD&S information of that service. If an 
optional field is specified both in the BCG and the SD&S information, then the field of the BCG shall be used. 

If the Logo element is present, it shall contain a URL that points to an image file. 

The ServiceURL element shall be present and shall contain a valid DVB locator that refers to a service, using the syntax 
given in clause 8 of the present document. 

6.7 OnDemandProgram fragment 

If the Instance Description field is present, its elements shall override the matching elements defined in the 
corresponding Program Information fragment. 

The PublishedDuration, StartOfAvailability, EndOfAvailability, FirstAvailability and LastAvailability elements in the 
OnDemandProgram element are optional. If the PublishedDuration element is not present, the value may be found in 
the Programlnformation fragment. If not present, it is undefined. If StartOfAvailability is not present, then the value of 
"now" is assumed. If EndOfAvailability is not present, then the value of "indefinitely" is assumed. These 
recommendations are summarized in table 5. 

Table 5: Default values for OnDemandProgram elements 



Element 


Default values 


PublishedDuration 


The value of the Programlnformation fragment, if present, else undefined. 


StartOfAvailability 


Now 


EndOfAvailability 


Indefinitely 


FirstAvailability 


Undefined 


LastAvailability 


Undefined 



The Program element shall be present and shall contain a GRID that can be found in the ProgramlnformationTable and 
this GRID should also be present in the GRI. 

The ProgramURL element may be present, to provide the location. If the ProgramURL element is present, it shall 
contain a RTSP URL. The dialog with the RTSP server shall comply with TS 102 034 [4], clause 6. 

The GRI shall be considered the authoritative source of GRID to location information. 

The InstanceMetadatald (IMI) may be present and when present the same IMI shall be available in the GRI. 

NOTE: The GRI can return a "not yet resolvable" flag in case the location is not yet available, but will be 
provided later. In this case it is recommended that the "StartOfAvailability" element is sent. 
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6.8 Purchase Information fragment 



The Purchaselnformation fragment shall be defined as in TS 102 822-3-2 [2], clause 4.3.1.10 and TS 102 822-3-1 [3] 
clause 6.3.4 (complex type PurchaseltemType), with the following recommendations: 

• A purchaseList element shall contain at least one Purchaseltem or PurchaseldRef. 

• Exactly one of the price attributes unit or currency shall be present. 

• If a PurchaseldRef is used, it shall contain a reference to a Purchase element that can be found in the 
TransactionlnformationTable. 

If the PricingServerURL is used, the returned information shall be a Data Delivery Unit containing a Pricinglnformation 
fragment. 



7 TV-Anytime Fragments 

7.1 Fragment encapsulation 

TV-Anytime fragments shall be delivered in Data Delivery Units, as defined in clause 4.1.1.3 of the present document, 
i.e. they shall be carried in containers within a compression wrapper and delivered either using HTTP or DVBSTP. 

7.2 Fragment encoding 

TV-Anytime fragments shall be encoded with BiM [10], as defined in TS 102 323 [1], clause 9.4. 



7.3 DVB-TVA-init message 



The DVB-TVA-init message shall be conformant to the DVB profile of the TVA MPEG-7 profile (BiM) as defined in 
TS 102 323 [1], clause 9.4.2.1. 

The DVB-TVA-init message shall be delivered, as defined in table 2 of the present document, using the Payload ID 
value OxAl. 



7.4 TVAMain fragment 



The TVAMain fragment, defined in TS 102 822-3-2 [2] contains the initial description of a TV-Anytime document. The 
transmission of this fragment is optional, as specified in TS 102 323 [1], clause 9.4.2.2. 

If transmitted, the TVAMain fragment shall be delivered as defined in table 2 of the present document, using the 
Payload ID value 0xA2. 

If not transmitted, the default TVMain fragment shall be used by the HNED, as specified in TS 102 323 [1] 
clause 9.4.2.2. 
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8 DVB locator extensions 



For referencing a service or content using the triplet { original_network_id, transport_stream_id, service_id } , the DVB 
locator format of TS 102 323 [1], clause 6.4 shall be used taking the DVBTriplet information from the SD&S 
BroadcastDiscovery record. 

The present document extends the DVB locator format defined in TS 102 323 [1] for referencing the location of a 
service or content directly from the BCG records. The following two ways are defined: 

• For services and content items available through RTSP, the format for RTSP URL (RFC 2326 [12]) shall be 
used: 

rtsp://<host>[:port] [/absolute_path] 

• For services and content items available by joining a multicast session, the following format shall be used: 

rtp://<host_address>[:port] [;source_address] 

where host_address is the multicast address of the service, and source_address is the optional address of the multicast 
source host. 

The previous syntax shall be used to reference an item of content when using TVA_id and time_duration as specified in 
TS 102 323 [1], for instance: 

• rtp://224.1.2.3:1234;;398298@2006-01-23T02:00:00Z/PT01H34M 
where 398298 is the TVAJd. 

Additionally, the signalling of availability start and end times for on-demand content shall use the following format: 

• @<window_start>;<window_end> 

where window_start and window_end are represented using ISO 8601 [13], for instance: 

• rtsp://www.foo.com:9090/mycontent @2006-01-01T00:00:00Z;2006-01-31T23:59:59Z. 



Usage of RTSP Methods 



Where RTSP is used to access content on demand, the RTSP DESCRIBE (TS 102 034 [4], clause 6.3.1.2) and 
ANNOUNCE Methods (TS 102 034 [4], clause 6.3.1.1) shall use an XML complex structure of the TV-Anytime type 
BasicContentDescriptionType. The namespace shall be specified at the start of the XML document, with the default 
being as specified in TS 102 323 [1]. 

The data shall be carried in unicast mode, as defined in TS 102 034 [4], clause 5.4.2. Specifically, this type shall be 
encoded as defined in clause 7.2, encapsulated as defined in clause 7.1 and the HTTP headers shall be defined as in 
clause 4.1.2.2.2 of the present document. The use of this type shall comply with the profiling set out in TS 102 323 [1] 
and clause 6 of the present document. 
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